Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes #38015 - Enable org and CVE scoping for flatpak content #11251

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

sjha4
Copy link
Member

@sjha4 sjha4 commented Dec 9, 2024

What are the changes introduced in this pull request?

Considerations taken when implementing this change?

  1. Use host's IP address to identify and then filter content based on host's repositories.
  2. If host is not identified, send the unfiltered flatpak index and allow normal flatpak operations. We could switch this tonot showing anything in the future once users are more accustomed to the flow?

What are the testing steps for this pull request?

Sync a few flatpak repos in different orgs and add them to some content view.
Create activation keys for those CVEs and then register a host using the key.
Setup a host to consume flatpak content from the katello server. Use server/index/static url instead of server/pulpcore_registry/ endpoint..
Try flatpak remote-ls and ensure you only see repos the host has access to.

@sjha4 sjha4 force-pushed the org_scope_flatpaks branch 2 times, most recently from eb3bc3d to 6bb32d1 Compare December 16, 2024 17:58
@sjha4 sjha4 changed the title Early Draft: Enable org and CVE scoping for flatpak content Enable org and CVE scoping for flatpak content Dec 16, 2024
@sjha4 sjha4 force-pushed the org_scope_flatpaks branch 2 times, most recently from 6f1e993 to 8373f5a Compare December 17, 2024 14:46
@sjha4 sjha4 changed the title Enable org and CVE scoping for flatpak content Fixes #38015 - Enable org and CVE scoping for flatpak content Dec 18, 2024
Copy link
Member

@ianballou ianballou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is working fine for me as-is. A question about the comment:

@@ -806,5 +806,25 @@ def render_podman_error(code, message, status = :bad_request)
def item_not_found(item)
render_podman_error("NAME_UNKNOWN", _("%s was not found!") % item, :not_found)
end

def static_index
host_ip = request.remote_ip
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why identify based on IP rather than hostname? Will this have implications for IPv6? In registration_manager we look at the hostname; there may be stuff you could reuse in there?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh I just remembered that in registration_manager it's the hostname of the capsule, not of the host. So possibly nevermind.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me see if I can grab hostname here..

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see something like this from resolv could work. We do something similar in foreman in atleast a text search I did on the repo.

Resolv.getname(request.remote_ip)

remote_ip should be able to provide ipv4 or ipv6 address whatever is passed to the request header by the client. As long as we store that on the host's nic ip, we should be able to get the host record.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should be able to resolve ipv4 or ipv6 address I believe via the same getname method.

I think one big question is if we should rely on Foreman's primary interface or DNS to resolve the IP to a hostname. Can we always rely on DNS being available? Foreman relies on DNS a lot so I think that might be true, but it might be worth asking someone from the platform side.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adamruzicka : Would you know if this is a good way to get the host from request.remote_ip and would this be ipv4/v6 proof?

Host.joins(:primary_interface).where("nics.ip = :host_ip OR nics.ip6 = :host_ip", host_ip: host_ip)&.first

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we always rely on DNS being available? Foreman relies on DNS a lot so I think that might be true

I would suggest against relying on this. Foreman may not be able to resolve hostnames that are managed by a dns server running in a remote location, even if that remote location's dns server is managed by a smart proxy. I'm also not sure if we also set up PTR records or just A/AAAA ones.

if we should rely on Foreman's primary interface

Why limit ourselves only to the primary interface?

Would you know if this is a good way to get the host from request.remote_ip and would this be ipv4/v6 proof?

From the top of my head I can't think of any other approach and it should be ip-version agnostic.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Adam!

Why limit ourselves only to the primary interface?

I found other instances of using primary interface to get/set host's ip address in foreman..Is there some other interface we can use for our purpose here?

From the top of my head I can't think of any other approach and it should be ip-version agnostic.

Updated to use the above query to look at ipv4 and ipv6..

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about collecting the IPs from all host interfaces? Host.first.interfaces ...

We'd be even more likely to get a hit in case a different NIC is used for flatpak.

@sjha4 sjha4 force-pushed the org_scope_flatpaks branch from 8373f5a to 15de19c Compare January 13, 2025 14:29
Copy link
Member

@ianballou ianballou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm cool with how this is now, if we get more information about a better set of interfaces to query we can make adjustments later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants